Write-observation and Read-preservation TM Correctness Invariants

A transactional memory (TM) is a concurrent object with the three read, write and commit methods. The clients of a TM are transactions, a sequence of read and write invocations that are possibly succeeded by a commit invocation. A transactional processing system is the composition of a TM and as set of clients. The clients issue the invocation events and the TM issues the response events. TM should guarantee that every concurrent execution of an arbitrary set of client transactions is indistinguishable from a sequential execution of them. Correctness conditions for TM such as opacity [7], VWC [11], and TMS1 and TMS2 [5] define the indistinguishably criterion and the set of correct histories. Considering the promised safety properties, designing a correct TM is an art. TM algorithms are subtle programs that compose a TM from a set of base concurrent objects. Their subtly makes them vulnerable. Lesani et al [14] reported bugs and fixes for a couple of previously proposed TM algorithms. Verification of TM algorithm has been a topic of recent attention. Researchers have employed model checking, automatic invariant generation and theorem proving to verify the correctness of TM algorithms. Model checkers from Cohen et al. [1, 2], and Guerraoui et al. [8–10] are the pioneering approach to verification of TM. Model checking can automate the verification process but is either based on assumptions about the TM algorithm or only scalable to a finite number of threads and locations or simplified algorithms. Later, Emmi et al. [6] tried to automatically infer invariants that are strong enough to entail the correctness criterion. Their research tackled the very central part of the problem but reported resorting to simplified algorithms due to scalability issues. Later, Lesani et al. [12] presented a machine checked theorem proving framework and a full proof of NORec TM algorithm [3]. The framework can be employed to verify realistic algorithms but requires translation of the algorithm to a transition system and more importantly, the process involves coming up with non-trivial invariants. Verification of TM algorithms has been a formidable problem in part because the target correctness criterion is a monolithic complicated condition. In an early work, Tasiran [15] presented a decomposition of the correctness condition for a specific class of algorithms. Can the correctness of TM be stated as a conjunction of simpler meaningful conditions? In other words, is there an intuitive functional decomposition of TM correctness conditions? What are the separate invariants that the TM designers should maintain? We present intuitive invariants for the correctness of TM algorithms. We say that a history is markable if there is a specific ordering relation called marking such that three invariants are satisfied. These invariants are not only required but also sufficient for opacity. We prove the equivalence of markability and opacity. Roughly speaking, the first invariant called write-observation requires that each read operation returns the most current value and the second invariant called read-preservation requires that the location which is read is not overwritten in a certain interval and the third invariant is the well-known real-time-preservation property. We will look at these invariants more closely in the next section. Separation of concerns brings modularity in understanding, design and verification. Decomposition of the correctness condition showcases different aspects of it. Separate required conditions informs designers and helps them concentrate on maintaining one condition at a time. It also allows studying the effect of separate correctness aspects on performance. In addition, separation has obvious benefits of modularity and scalability for verification. The marking relation can be defined using the execution order or the linearization order of method calls on the used base objects. Thus, proofs of markability can be aided by and mirror design intuitions. Another important property of markability statement is that it can be proved using a program logic that we are developing. We are working on a machine checked proof of markability of the TL2 [4] algorithm.